一种SpringBoot下Scheduler定时任务优雅退出方案 |
您所在的位置：网站首页 › java定时任务scheduled 线程池 › 一种SpringBoot下Scheduler定时任务优雅退出方案 |
|
背景
近期业务中有一个定时任务发现每次服务部署时，偶发性的会触发问题，这里记录一下问题的跟进解决。 分析现象该定时任务每2分钟执行一次，完成数据的更新处理。同时服务部署了多个服务器节点，为保证每次只有一个服务器节点上的任务在跑，引入了基于Redis缓存的分布式锁。 示例源码 @Scheduled(cron = "10 */2 * * * ?") public void execute() { String jobName = getJobName(); DistributeLock lock = distributeLock.newLock(getJobKey(), 5 * 60); if (!lock.tryLock()) { logger.info(" {} execute get lock faild......", jobName); return; } try { logger.info("execute start........ {}", jobName); long startTime = System.currentTimeMillis(); doExecute(); long endTime = System.currentTimeMillis(); logger.info("execute end........,time:{} ms", (endTime - startTime)); } catch (Exception e) { logger.error("execute error", e); } finally { lock.unlock(); } }当服务部署时，分析日志发现存在以下异常。 任务存在开始日志，但是缺少执行结束时候的日志。新服务启动后，会存在空的运行周期，所有的节点获取锁失败。原因： 我们假设任务在具体执行doExecute方法时，服务器节点收到了重新部署的命令。 那么此时JVM进程会被kill，由于JVM直接被kill，并没有任何优雅退出的处理，此时也就不会有任务执行结束的日志.同样的，上述代码中的finally语句也不会被执行到，所以锁就不会被释放。由于锁未被及时释放，当下一个2分钟执行周期来到时，我们看到上一个锁的时间是5*60s，此时是无法获取锁的，导致空了一个定时任务周期。 解决方案 方案1：缩短锁的持有时间将锁的持有时间修改为2分钟，考虑到通常的节点部署时间是超过2分钟的，这样可以保证新服务部署的时候，上一个锁是已经过期的。 看似是可以解决问题的，那么实际可以的吗。其实不然，这种方案是有风险的，因为这里忽略了doExecute的实际执行时间。 原有的5分钟是确定任务最长执行时间不会超过5分钟，但是将锁过期时间设置2分钟实际是否风险的。 举个例子： 10:00 任务1开始执行，执行时间为3分钟，要到10:03才会结束。 10:02 任务2开始执行，此时任务1还在执行，但是由于锁已经过期了，此时任务2也开始执行，要到10:05才会结束。 这就会导致，同一时刻，会存在重叠的任务在执行。 所以不能冒然调整锁的持有时间。 方案2： 利用钩子在服务器停止的时候，将锁显示释放该方案依赖Spring或者JVM的关闭钩子，在进程销毁的时候，进行一些清理工作。 比如可以依赖Spring的ApplicationListener监听ContextClosedEvent事件。 @Component @Slf4j public class DistributeLockShutdownHook implements ApplicationListener { @Override public void onApplicationEvent(ContextClosedEvent event) { log.info("shutdown hook, ContextClosedEvent"); // 先判断当前节点是否持有定时任务的锁，如果持有 // 利用redis缓存的api，直接删除定时任务持有的锁； // 如果不持有锁，不做处理。 } }这样可以保证锁是清理掉的，后续启动的节点就可以成功获取锁了。 不过这里有一点要注意，在清理时，一定是当前节点之前持有了这把锁才清理。否则，如果不做判断直接清理，就会出现问题，这通常与我们服务部署时，是按照百分比部署有关系。 10:00 B节点正在执行任务，持有锁，任务执行3分钟。 10:01 A节点此时要重新部署服务，将锁删除 10:02 C节点开始执行任务，获取锁成功，也开始执行任务。 那么此时也会导致多个任务在重叠执行。 方案3： 通过定制化线程池，等待当前定时任务执行完成优雅退出可以看到方案1和方案2，当前正在执行的任务都是直接被终止掉了，那是否有办法等待当前定时任务执行完成，再关闭JVM呢。可以尝试使用以下方案。 首先，我们给Spring Schedule定时任务指定了线程池，同时配置了线程池的关闭策略和关闭等待时间。 @Configuration public class ThreadPoolTaskSchedulerConfig { @Bean public ThreadPoolTaskScheduler threadPoolTaskScheduler () { ThreadPoolTaskScheduler threadPoolTaskScheduler = new ThreadPoolTaskScheduler(); //线程池大小为10 threadPoolTaskScheduler.setPoolSize(10); //设置线程名称前缀 threadPoolTaskScheduler.setThreadNamePrefix("scheduled-thread-test-"); //关键点: 设置线程池关闭的时候等待所有任务都完成再继续销毁其他的Bean threadPoolTaskScheduler.setWaitForTasksToCompleteOnShutdown(true); //关键点：设置线程池中任务的等待时间，如果超过这个时候还没有销毁就强制销毁，以确保应用最后能够被关闭，而不是阻塞住 threadPoolTaskScheduler.setAwaitTerminationSeconds(60); threadPoolTaskScheduler.initialize(); return threadPoolTaskScheduler; } } @Configuration public class SchedulerConfig implements SchedulingConfigurer { @Resource private ThreadPoolTaskScheduler threadPoolTaskScheduler; @Override public void configureTasks(ScheduledTaskRegistrar scheduledTaskRegistrar) { scheduledTaskRegistrar.setTaskScheduler(threadPoolTaskScheduler); } }然后监听Spring的ContextClosedEvent，在其中触发线程池的shutdown方法。 @Component @Slf4j public class ShutdownHookDemo implements ApplicationListener { @Resource private ThreadPoolTaskScheduler threadPoolTaskScheduler; @Override public void onApplicationEvent(ContextClosedEvent event) { log.info("shutdown hook, ContextClosedEvent"); threadPoolTaskScheduler.destroy(); } }对于ThreadPoolTaskScheduler的destroy方法，源码如下所示： 可以看到会触发ExecutorService的shutDown方法，等待任务执行完成。而awaitTerminationIfNecessary方法则是限时等待，如果超时，则将线程中断。 /** * Calls {@code shutdown} when the BeanFactory destroys * the task executor instance. * @see #shutdown() */ @Override public void destroy() { shutdown(); } /** * Perform a shutdown on the underlying ExecutorService. * @see java.util.concurrent.ExecutorService#shutdown() * @see java.util.concurrent.ExecutorService#shutdownNow() */ public void shutdown() { if (logger.isInfoEnabled()) { logger.info("Shutting down ExecutorService" + (this.beanName != null ? " '" + this.beanName + "'" : "")); } if (this.executor != null) { if (this.waitForTasksToCompleteOnShutdown) { this.executor.shutdown(); } else { for (Runnable remainingTask : this.executor.shutdownNow()) { cancelRemainingTask(remainingTask); } } awaitTerminationIfNecessary(this.executor); } } private void awaitTerminationIfNecessary(ExecutorService executor) { if (this.awaitTerminationMillis > 0) { try { if (!executor.awaitTermination(this.awaitTerminationMillis, TimeUnit.MILLISECONDS)) { if (logger.isWarnEnabled()) { logger.warn("Timed out while waiting for executor" + (this.beanName != null ? " '" + this.beanName + "'" : "") + " to terminate"); } } } catch (InterruptedException ex) { if (logger.isWarnEnabled()) { logger.warn("Interrupted while waiting for executor" + (this.beanName != null ? " '" + this.beanName + "'" : "") + " to terminate"); } Thread.currentThread().interrupt(); } } }这样我们可以根据任务最大的超时时间，设置线程池属性，在JVM关闭时等待线程池中的任务执行完成。 方案对比： 方案3的实现会导致部署时间的增加，但是可以确保当前定时任务处理完成。方案1和方案2会对当前任务不做处理，同时方案1会存在一定的风险。可以结合实际业务场景需要进行选择，当然这里只有方案3才是优雅退出。 补充提到优雅退出，实际Spring有针对web的优雅退出。 修改application.properties配置文件，将server.shutdown从默认的immediate修改为graceful.同时设置等待时间为60s。 也就是说当收到退出请求时，如果此时有web请求还在处理，那么可最多等待60s后再退出。 server.shutdown=graceful spring.lifecycle.timeout-per-shutdown-phase=60s { "name": "server.shutdown", "type": "org.springframework.boot.web.server.Shutdown", "description": "Type of shutdown that the server will support.", "sourceType": "org.springframework.boot.autoconfigure.web.ServerProperties", "defaultValue": "immediate" } { "name": "spring.lifecycle.timeout-per-shutdown-phase", "type": "java.time.Duration", "description": "Timeout for the shutdown of any phase (group of SmartLifecycle beans with the same 'phase' value).", "sourceType": "org.springframework.boot.autoconfigure.context.LifecycleProperties", "defaultValue": "30s" }当存在一个正在处理的耗时web请求，当进程关闭时，日志中会包含以下信息 2023-08-05 00:16:32.264 o.s.b.w.e.tomcat.GracefulShutdown : Commencing graceful shutdown. Waiting for active requests to complete 2023-08-05 00:17:32.278 o.s.b.w.e.tomcat.GracefulShutdown: Graceful shutdown aborted with one or more requests still active最后再强调一次，这里无论哪一种优雅退出，都是针对的kil -15这种操作，这是操作系统给了应用进程优雅退出的机会，如果是kill -9那么就不存在优雅退出了，因为会被立即停止执行。 |
今日新闻 |
推荐新闻 |
| CopyRight 2018-2019 办公设备维修网 版权所有 豫ICP备15022753号-3 |